Business applications, such as Web-based electronic commerce applications, are well known in the art. A typical high-level abstraction for such applications is illustrated in FIG. 1, in which an application 100 comprises a presentation layer 102 that communicates with a business layer 104 that, in turn, communicates with a data layer 106. Typically, the presentation layer 102 implements those functions used in presenting information to, and receiving inputs from, a user of the application, e.g., a person attempting to purchase goods or services via the business application. When certain tasks need to be performed to complete the interactions with the user, the presentation layer 102 interacts with the business layer 104 that typically encompasses the functions necessary to achieve the purpose of the application, e.g., verify a user's credit, verify availability of the requested product, complete the purchase, etc. To complete these functions, the business layer 104 communicates with the data layer 106, typically implementing suitable database and database management system functionality, to process the requisite data.
In developing such applications, it is often the case that the various layers 102-106 are developed in such a way that they are very co-dependent upon the implementation of each other. For example, web applications developed on JavaServer Pages are known to sometimes commingle database code, page design code, and control flow code. As a result, it becomes difficult to complete development of any one layer without the simultaneous development of other layers, thereby often unnecessarily delaying development of a given layer.
Given this, so-called application frameworks are known to provide means for independently developing various layers in business applications. For example, the well-known “STRUTS” framework provided by the Apache Software Foundation uses a Model-View-Controller (MVC) architecture, wherein the “model” represents the business or database code, the “view” represents the page design code, and the “controller” represents the navigational code. This framework also provides three key components: (a) a “request” handler provided by the application developer that is mapped to a standard web address; (b) a “response” handler that transfers control to another resource which completes the response, and (c) a tag library that helps developers create interactive form-based applications with server pages. However, the complexities associated with this framework hinders developers who may desire to have the flexibility of migrating to other frameworks.
The “SPRING” framework provided by SpringSource, Inc. is another well known framework. This framework can provide some solutions to technical challenges faced by Java developers and organizations wanting to create applications based on a Java platform and can be considered a collection of numerous smaller frameworks that are designed to work independently of each other so as to provide some improved functionalities when used together. However, the “SPRING” framework requires the interoperation of these numerous smaller frameworks in order to operate efficiently. This ultimately makes this framework solution very complex to implement.
As a result, there is still the need to develop a simple and robust solution for business application frameworks that are known to have highly coupled presentation and business layers. These solutions are desired in that current developers of presentation layer components invariably have to wait for the developers of the business layer components, and vice versa, in order to complete a project.